Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / info-service / gopher / gopher_protocol / Gopher+ / Gopher+AttributeRegistry < prev next >

Wrap

Text File | 1993-02-16 | 14.0 KB | 432 lines

WARNING: THIS DOCUMENT IS PRELIMINARY AND SUBJECT TO CHANGE. ALTHOUGH WE DO NOT EXPECT ANY SIGNIFICANT CHANGES TO THE ATTRIBUTES DEFINED HERE, NOT ALL ATTRIBUTES HAVE BEEN IMPLEMENTED SO IT IS POSSIBLE THAT THERE MAY BE CHANGES... - the GOPHER team, University of Minnesota Registry of Gopher+ Attributes. ------------------------------- Last Revised 16 February 1993 0. Use of this document. ------------------------- This document serves as the authoritative registry of Gopher+ attribute block names and the guide for the interpretation of the content of attribute blocks. The primary consumers of this document are authors of Gopher+ clients and servers, as well as administrators of Gopher+ servers. It is recommended that the basic Gopher and Gopher+ protocol documents be read and understood before attempting to use this document. If you wish to register a new attribute block, add to the possible content of an attribute block (eg. register a new alternative view type) etc., send your request (in a form suitable for inclusion in this document) to <gopher@boombox.micro.umn.edu> It will be forwarded (perhaps with minor edits), to both the gopher-news mailing list and to the usenet newsgroup comp.infosystems.gopher for possible discussion by the gopher community. Assuming no violent disagreements and including perhaps minor changes, your request will be incorporated into the Registry with minimum fuss. Gopher+ server implementations, client implementations, or administrators are not required to show or use any attributes other than the small, core, required set. Server implementations may have no provision for specifying certain kinds of attributes. Clients may have no way to use certain kinds of attributes, and all client must be able to ignore everything they do not use. Server administrators may at their option include or exclude attribute besides the basic set. Throughout this document, the "#" character is used to represent an ASCII TAB character. Information in brackets "[....]" are optional parts of attributes. Any attribute block may include a Gopher+ descriptor on the same line as the attribute name. In the case of the +INFO block, the Gopher+ descriptor is mandatory and identifies the item whose attributes follow. In all other cases, the descriptor is optional (typically absent), and if present, points at a gopher item which contains the actual attribute contents. If both a gopher descriptor pointing to an attribute as well as the attribute block exist, the client will use the immediately following block rather than the information indirectly accessible via the gopher descriptor. Attribute Block names start with "+" as the first character on the line, and cannot contain "+" within the attribute name. The lines constituting the contents of a block all start with a space character (in other words, the block content is "indented" by one space). 1. The +INFO attribute block. ------------------------------ The +INFO attribute block for any item is a minimal, 1-line block that serves only to bear the full Gopher+ descriptor of the item for identification purposes, and in the case of a list of attributes (such as would be sent in response to the Gopher+ "$" command), also separates one item's attributes from the next one. An example of such a block would be: +INFO: 0displayName#selector#hostName#port#+ All Gopher+ servers must include a +INFO attribute block as the very first block in the list of attributes for an item (such as would be returned in response to a "!" command). Furthermore, all Gopher+ servers must include include a +INFO attribute block as the first block for each item in a list of item attributes (such as would be returned in response to a "$" command). 2. The +ADMIN attribute block. ------------------------------- The +ADMIN block contains administrative information for an item. All Gopher+ servers must include a +ADMIN block when returning the list of attributes for an item. If the client has specifically requested just some specific attributes not including +ADMIN (for example using the +VIEWS or $+ABSTRACT commands), then if the server is capable of just sending selected attributes, it may omit the +ADMIN block. The +ADMIN block must include at least two attributes when it is present: the Admin attribute and the Mod-Date attribute. An example +ADMIN block follows: +ADMIN: [0displayName#selector#hostName#port#+] Admin: Joe Gopher <joe@gopher.bogus.edu> Mod-Date: 30 August 1992 <19920830103300> 2.1 The Admin attribute (+ADMIN block) -------------------------------------- The Admin attribute contains the email address of the administrator of the server in standard RFC 822 format. The email address must be enclosed in angle brackets for easy extraction by the client. Any text outside the angle brackets is considered a comment, typically containing the full name of the administrator, perhaps with a phone number. Eg: Admin: Joan Gopher, (612) 555-1212 <joan@gopher.bogus.edu> 2.2 The Mod-Date attribute (+ADMIN block) ----------------------------------------- The Mod-Date attribute contains the date of last modification of the item. The date, if known, is enclosed in angle brackets for easy extraction by the client. If there are no angle brackets on the line, the modification date is unknown (the server cannot or chooses not to tell you). The format of the date is <YYYYMMDDhhmmss> (YYYY=year, MM=month, DD=day, hh=hour in 24 hour format, mm=minute, ss=second). Any text outside the angle brackets may contain the date in local (user readable) format. Eg: Mod-Date: 30 August 1992 <19920830100300> 3 The +ABSTRACT attribute block. ---------------------------------- The +ABSTRACT block contains a short abstract describing the contents of the item. Eg. +ABSTRACT: [0displayName#selector#hostName#port#+] This document contains the list of closed classes for the Fall Quarter 1992 in the Department of Obfuscation at the University of Minnesota. 4 The +VIEWS attribute block. ------------------------------- The +VIEWS block contains of alternative views for an item. For example, most gopher documents are text files. These files are ASCII text only, and so devoid of any elaborate formatting, font information etc. An alternative view of such a document might be a Postscript rendering, or a Rich Text version. The content of these "alternative representations" is the same as that of the basic text, but might include additional information such as diagrams or pictures. The default or standard view of basic gopher text documents is the basic text view. Directories (lists of Gopher items) may also have alternative views, as may other gopher items. For more information on +VIEW blocks, please read the Gopher+ protocol document. Note that Gopher+ Image files (type "I") have NO default type; the client must check to see what representations are available before attempting a transfer. The general format of a gopher+ view descriptor is: xxx/yyy zzz: <nnnK> where xxx is a general type-of-information advisory, yyy is what information format you need understand to interpret this information, zzz is a language advisory, and nnn is the approximate size in bytes. Examples: Text <25K> Text de_DE: <54K> Text/Postscript de_DE:<187K> The first example view is text, the second view is text in German, and the third view is a postscript rendering of text in German. Another example describing an image in gif format with the Japanese language advisory (perhaps there are kanji characters in the image...): image/gif Jp_JP: <1024K> The choices for the type of information advisory are: text file image audio video smell tactile terminal The options for information format depend on the type of information as follows: 4.1 Text Text type information views should ALWAYS include a plain ascii version of the information so that the lowest common denominator is accommodated. If the information format is not specified, then the client assumes ascii text. The values for text format are as follows: text text/unicode text/postscript text/sjis text/jis text/euc text/gb text/big-5 text/rtf text/msword text/macwrite text/mime text/tex text/dvi Notes: Most of the information format should be obvious. MIME is (of course) Multi-media internet mail extension format a way of encoding binary information into a 7 bit data stream. Rtf is microsoft's rich text format, big-5 is an encoding of kanji characters into ascii text as are gb, euc, jis, and sjis. 4.2 File (binaries) File format information in general assumes that the client will take the byte stream and store it to a disk file. It is STRONGLY recommended that client software not automatically launch binary files without giving the user the option of skipping the launch... because of potential problems with virus transmission. If no format is specified, then the raw byte stream can be written to a file without interpretation. However, there are several common coding/compression schemes which may require the client to decode or decompress the information sent from the server. The values are as follows: file file/hqx file/uuencode file/tar.z file/unixcompress file/zip file/tar file/zoo file/arc file/lharc file/pcexe file/macbinary 4.3 Image Image format information does not have a default format so clients will have to fetch the alternate views to know how to render the image. The values are: image/gif image/jpeg image/pict image/jfif image/tiff image/pcx image/pbm image/pgm image/ppm image/postscript image/eps Notes: Again, most of these formats should be obvious. GIF is also known as Compuserve Graphic Interchange Format. The content of gif images is binary and viewers exist for UNIX, Macs, PCs. PICT is a common Macintosh picture format with a binary content. TIFF (Tagged Image File Format) is another common graphic format with binary content. 4.4 Audio Audio format information does not have a default format; client software will need to fetch the alternate views to know how to play the audio. The formats are: audio/ulaw audio/wave audio/snd 4.5 Video Video format information does not have a default format, so once again the client software will have to fetch alternate views to know how to play the video. The values for the video view attributes are: video/quicktime video/mpeg 4.6 Smell Digitized smell information is an exciting new frontier for networked information servers. Alas, the lack of standards in the area mean that most digitized smells will be represented as ascii text words. However, and alternate view format for the soon-to-emerge digital funky small format may be supported someday (in your dreams). smell/ascii smell/funky 4.7 Tactile Digitized tactile information will be important as the Internet becomes more commercialized and paying customers demand sensational applications. For now we must content ourselves with ascii words describing digital tactile information but the long awaited digital touch standard will be accommodated as an alternate view. tactile/ascii tactile/touch 4.8 Terminal session information is not really well defined yet. We need to make this work cross platform somehow. These are really placeholders for when we figure out what to do here. terminal/telnet terminal/tn3270 4.9 Language tags are coded using the POSIX definitions. Here are the POSIX definitions for some languages: Danish Da_DK Dutch (Belgium) Nl_BE Dutch Nl_NL English (Great Britain) En_GB English (US) En_US Finnish Fi_FI French (Belgium) Fr_BE French (Canada) Fr_CA French (Switzerland) Fr_CH French Fr_FR German (Switzerland) De_CH German De_DE Greek El_GR Icelandic Is_IS Italian It_IT Japanese Jp_JP Norwegian No_NO Portuguese Pt_PT Spanish Es_ES Swedish Sv_SE Turkish Tr_TR 5. The +ASK attribute block. ----------------------------- The content of the +ASK attribute block is a series of questions (one to a line) that the client must ask the user in the order in which they are specified in the block. The user's (say 3) replies are sent to the server (in this case as the first 3 lines) in the data block. If a file is to be sent to the server, this is sent in the last part of the client's (normally absent, optional) data block. For more information see the Gopher+ protocol document. 5.1 Ask question (+ASK) The Ask line specifies a question and an optional default answer to present to the user. The default answer (if any) is separated from the question by a TAB. The user's reply is to be sent to the server. Examples: Ask: Transfer files (by FTP) from:#wuarchive.wustl.edu Ask: Your VISA card number? 5.2 AskF question (+ASK) The AskF line presents the user with a one-line request for a local file to hold the information that the server is about to send. The request may include a tab-separated default filename. The client should save the data the server sends in the file rather than attempting to display it. Eg: AskF: Save requested viral RNA sequence as?#T7-sequence 5.3 Choose question (+ASK) The Choose line presents the user with a one-line question, and a few tab separated choices (there may be one to three choices, eg. Yes, No, Cancel). The user's selection is sent to the server in the client's data block. Eg. Choose: Display results in miles or kilometers?#Miles#Km 5.4 ChooseF The ChooseF line requests a local file from the user, using a one line prompt. The client should send the contents of this file to the server in the client's data block. If the file is a text file the client should respect normal text file transfer conventions; if not a text file the client should assume it is binary and send it appropriately. Eg: ChooseF: File containing target DNA sequence?